…_TOKEN header doc + grammar (#424)

- **#405 P1 (Codex):** empty provenance cone now FAILS G_carrier_overlap
  (treats missing-lineage as suspicious, not best-case). Prior fix made
  overlap=0 which let provenance-empty + advisory-evidence-v0 stack into
  GREEN — the carrier-laundering safeguard would have missed exactly the
  records that should trigger review. Now the gate definition reads:
  fail-RED on (overlap > θ_high) OR (cone empty); fail-YELLOW on
  (overlap > θ_med).
- **#411 P1 (Copilot):** gate.yml header 'No secrets referenced' was
  inaccurate after I added the workflow-level GITHUB_TOKEN env. Updated
  the header bullet to name the token explicitly + reference its
  read-only inheritance from permissions: contents: read + the
  workflow-vs-step-scope trade-off (DRY for ~7 install steps).
- **#413 P2 (Copilot):** 'requires any modify' → 'requires any
  add-or-modify on' grammar fix.

Note on #411 P2 (restrict GITHUB_TOKEN to install steps): trade-off
documented in the header bullet rather than refactoring 7 install steps
to per-step env. Reply explains.

Note on #415 (name attribution in drain-log): docs/pr-preservation/ is
a HISTORY surface per Otto-279 — names are policy-correct there.
Reply explains.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…#453)

Otto-268 follow-on: drain-log for the **maximum-multi-parent cascade**
observed in this drain wave — #424 was a follow-up to FOUR parent PRs
simultaneously (#405 empty-cone + #411 GITHUB_TOKEN header + #413
grammar + #415 Otto-279 policy reply). Composes-vs-serializes
tradeoff favored compose: one commit + one merge gate addressed all
four parents.

Per Otto-250 training-signal discipline. Pattern observations:

1. Maximum-multi-parent cascade: 4 parents in one follow-up. Composes
   when findings are independent + small. #423 had 2 parents; #424
   doubled to 4.
2. fail-YELLOW vs fail-RED on structurally-normal empty-input cases
   (empty cone, zero qualifying findings, no diff to lint) — over-
   blocking risk when fail-RED on empty-input. CI-design candidate:
   every audit script should explicitly classify "empty-input"
   behavior at design time.
3. GitHub canonical-example form (`Authorization: token
   $GITHUB_TOKEN`) vs accepted-also (`Authorization: Bearer
   $GITHUB_TOKEN`); prefer canonical for reader friction reduction.
4. Otto-279 surface-class reply remains stamp-uniform across the
   corpus regardless of multi-parent grouping; the multi-parent
   grouping doesn't change per-finding response.